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(57) Abstract 



In order to supply messages to an audience of Internet 
users, the messages are initially stored on an Internet server 
(20) which is accessible by a group of Internet clients (21 to 
32) operated by Internet users. When a message is received 
at the server (20), it comprises an information part and a 
data part. Hie data part includes at least one identifier 
specifying the intended audience of the message. In the 
server (20), the information part of the message is stored 
as an HTML file in a first store and the URL of the file 
containing the information part of the message together 
with the identifier or identifiers of the intended audience 
are stored in a second store. In order to view messages 
intended for a particular user on one of the clients (21 to 
32), the client transmits requests automatically at periodic 
intervals to the server (20) for new messages intended for 
the user. In response to each request, the server scans the 
fields in the second store to compile a list of URLs of 
messages intended for the user. The list is then transmitted 
to the client which then requests the HTML files for the 
messages specified on the list. The HTML files are then 
transmitted to the client where the messages are displayed. 
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MESSAGE SERVICE 

This invention relates to a method of supplying messages. 

In a well known method of transmitting messages to an intended 
5 audience, the messages are transmitted as e-mails to computers operated by 
members of the intended audience. However, as is also well known, messages 
transmitted as e-mails are prone to unpredictable delays. For some messages, 
such delays are unacceptable. 

According to this invention, there is provided a method of supplying 
10 messages in which: 

messages are stored on a server which is accessible by a group of clients 
operated by users, each message being stored by performing the following 
operations: 

receiving the message at said server from one of said group of clients, said 
1 5 message comprising an information part and a data part, the data part including at 
least one identifier specifying the intended audience of the message; 

storing the information part of the message as a file at an address in a first 

store; 

storing said address and said at least one identifier in a second store; and 
20 messages intended for a particular user are viewed on one of said clients 

by performing the following operations: 

said client transmitting requests automatically at periodic intervals to the 
server for messages intended for said particular user; 

in response to each request, the server scanning the second store to 
25 compile a list of addresses of messages intended for said particular user; 

the server transmitting files stored at addresses specified on said list to 
said client; and 

said client displaying messages received by the client. 

In the method of this invention, because the messages are stored on the 
30 server as files and then transmitted to clients operated by intended recipients as 
files, they are not subjected to the unpredictable delays experienced by messages 
transmitted as e-mails. Also, because a client which is being used for viewing 
messages intended by a particular user transmits requests automatically at periodic 
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intervals to the server for messages intended for the particular user, an up-to-date 
set of messages can be viewed by the particular user. 

This invention will now be described in more detail, by way of example, 
with reference to drawings in which: 
5 Figure 1 shows a group of Internet clients which are able to post 

messages on, and receive messages from, an Internet server, in accordance with 
this invention; 

Figure 2 is a block diagram of the programs installed on the Internet server 
shown in Figure 1; 

10 Figure 3 is a block diagram of the software programs installed in each of 

the Internet clients shown in Figure 1 ; 

Figure 4 is a flowchart of the operations which are performed when one of 
the Internet clients posts a message on the Internet server shown in Figure 1; 

Figure 5 is a flowchart showing the operations which are performed to 
1 5 enable one of the Internet clients to retrieve messages from the Internet server of 

Figu r e~ 1 ;~a nd 

Figure 6 shows the screen layout used to display messages on one of the 

clients. 

As is well known, the Internet is a combination of interconnected 
20 networks which can support transfer of communications between computers using 
the well established TCP/IP protocols. A computer which can access the Internet 
for transmitting and receiving communications protocols will be referred to as an 
Internet computer. Some Internet computers are configured to store information 
for retrieval by other computers. Computers which are configured to store 
25 information will be referred to as "servers" and computers which are configured to 
retrieve information from servers will be referred to as "clients". Some 
organisations operate a private network which can support transfer of 
communications using the TCP/IP protocols. Such a network is known as an 
intranet. Private intranets may be connected to the Internet. In this specification, 
30 the terms "Internet client" and "Internet server" are intended to include, 
respectively, a client or a server connected to a private intranet. Also, although 
the Internet as presently known uses the well established TCP/IP protocols for 
transferring communications, it is envisaged that other protocols may be used in 
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the future. Accordingly, the term Internet is intended to included networks which 
are capable of transferring communications using other protocols. 

Referring now to Figure 1, there are shown four networks 10, 11, 12 and 
1 3 belonging to a particular organisation and which are located, respectively, at 
5 London, Amsterdam, New York and Australia. An Internet server 20 and Internet 
clients 21 to 24 are connected to the network 10, internet clients 25 to 28 are 
connected to the network 1 1, Internet clients 29, 30 are connected to the network 
12 and Internet clients 31 to 33 are connected to the network 13. The clients 21 
to 33 are operated by users who are members of the organisation. A particular 
10 user may predominately operate one of the clients 21 to 33. However, it may 
happen that a particular user operates more than one of the clients, for example as 
the user moves from one location to another. It may also happen that one of the 
clients 21 to 33 is operated by two or more users, for example a day shift user 
and a night shift user. 

15 The networks 10 to 13 are connected, respectively, to routers 35 to 38. 

The routers 35 to 38 are interconnected by one of more further networks shown 
simply, in well known manner, as a cloud 34. The networks 10 to 13, the routers 
35 to 38 and the networks 34 can support Internet communications. In addition to 
supporting transfer of communications using the TCP/IP protocols, the Internet 

20 also support services which use higher level, dedicated protocols. One of these 
services is the well known World Wide Web (the Web) service. In the Web service 
information is stored on servers as HyperText Mark-up Language (HTML) files. 
The address of a particular HTML file on a particular server is defined by the 
Universal Resource Locator (URL) of the file. An Internet client equipped with a 

25 Web browser can retrieve an HTML file from a Web server using the HyperText 
Transfer Protocol (HTTP). When an HTML file is transmitted across the Internet 
using the HTTP protocol, the HTTP information is wrapped in the TCP/IP protocol. 
When an HTML file is retrieved by a client using a Web browser, the file is 
interpreted by the browser and the textual and graphical information is then 

30 displayed appropriately on a display screen. 

As will be described in more detail below, the server 20 and clients 21 to 
33 are arranged to provide a message service for the users. In this message 
service, a user can operate one of the clients 21 to 33 to post a message on the 
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server 20 and to specify the audience for whom the message is intended. The 
audience may be ail of the users or a selected set of the users. For example, the 
audience could be all of the users in New York, all of the users who have a 
particular level of responsibility in the organisation, all of the users who perform a 
5 particular function within the organisation or all the night shift users. By operating 
one of the clients 21 to 33, a user may retrieve the messages intended for him or 
her. 

The users of the clients 21 to 33 collectively form a defined group of 
users. The message service is not available to people outside this defined group. 
10 Although in this example the message service is provided by clients and a server 
which are connected to networks belonging to a particular organisation, the 
invention could also be implemented with a set of appropriately equipped clients 
and a server which are connected to the Internet without using a private network 
and which are operated by a defined group of users. 
15 Referring now to Figure 2, there are shown the software -programs 

-.nstaHedJn-ser-ver_20-to-prov4de-the-messageservi e e^-T-hese^programs- C omprrse-a- 



program 50 which enables the server 20 to operate as a Web server, a program 
BACKEND 51 and a program MSGPOST 52. Software to enable a server to 
operate as a Web server is commercially available. The functionality of the 

20 programs BACKEND and MSGPOST will be described below. In order to provide 
the message service, the server 20 has also three stores 53, 54 and 55. As will 
be described in more detail below, the store 53 stores the information part of 
messages, the store 54 stores the data part of messages and store 55 stores data 
on the users of the information service. In this example, the stores 53, 54 and 55 

25 are located in the same database and this database forms part of the server 20. 

Referring now to Figure 3, there are shown the programs which are used 
in each of the clients 21 to 33 to enable the clients to use the message service. 
These programs comprises a Web browser 63, a program DISPLAY 61 and a 
program INVOKER 62. Web browser programs are commercially available, and by 

30 way of example, the Web browser 63 may be a Netscape (Trademark) browser. 
The operation of the programs DISPLAY and INVOKER will be described below. 
On the first occasion that a client uses the message service, and as will be 
described below, the programs DISPLAY and INVOKER are downloaded to the 
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client from the server 20. Thus, initially, in order to use the message service a 
client needs only a Web browser. In order for a user to use the message service, it 
is necessary for details of the user to be registered in the user data store 55 of 
server 20. 

5 Referring now to Figure 4, there will now be described the series of 

operations which are performed when a user posts a message on the server 20. 

In an initial step 70, the user operates one of the clients 21 to 33 to log 
on to the server 20. In order to do this, the user selects the URL for the message 
service provided by the server 20. The user is then invited to enter his user 
10 identifier and password. These are checked against data held in store 55. 

In step 71. the server 20 invites the user to make a choice between the 
option for posting a message and the option for retrieving messages. The user 
selects the option tor posting a message. 

Then, in a step 72, the user again enters a user identifier. (The message 
1 5 service may be configured so that that the same user identifier is used in steps 70 
and 72 or different identifiers are used in these two steps). The function of step 
72 is to identify the user to the message service. 

In this example, the service is capable of handling two types of messages. 
These are short messages which have a short text and normal messages which 
20 can have up to a whole page of text. Although in this example the messages are 
not capable of handling graphical information, the message service described in 
this example could easily be modified so as to handle graphical information and any 
other multimedia file type. 

In a step 73, the user selects the type of message which he wishes to 
25 post. Next, in a step 74, the server sends a file to the user containing a form. 
This form contains a set of fields which, when completed, will contain the details 
of the message which is to be posted. 
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The fields of the form for posting a normal message are shown in Table 1 



below. 

TABLE 1 



EXPIRY: 


time of expiry 


DISPLAYTIME: 


intended display time 


AUDIENCE: 


identifier(s) of audience 


TEXT: 


text of message 



The individual fields of the form for a normal message will now be 
described. Messages transmitted by the message service have a finite lifetime. 
The field EXPIRY contains the time of expiry of the message. As will be explained 
below, when a user uses a client to view his messages, the normal messages are 

10 displayed in turn and each message is displayed for a period of time which has 
been specified by the originator of the message. The field DISPLAYTIME contains 
the period for which the message should be displayed. 

The AUDIENCE contains the identifier or identifiers of the intended 
audience of the message. If the originator of a message wishes to supply a 

1 5 message to all users of the message service, he enters in this field the identifier for 
all users. If the originator wishes to supply the message to one or more groups of 
the users, he enters the identifier or identifiers for such groups. Examples of such 
groups are all users located in Australia, or ail night shift users or all users having a 
particular responsibility within the organisation. If the originator wishes to supply 

20 the message to one or more specified users, he enters the user identifier for each 
such user. 

The field TEXT contains the text of the message. 

The form for short messages has only the fields EXPIRY, AUDIENCE and 



TEXT. 



25 



In a step 75, the user fills out the form and returns it to the server 20. 

Next, in a step 76, if the message is a normal message, the server 20 
stores the information part of the message as an HTML file in store 53. The 
information part of the message is the contents of the field TEXT. 
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Lastly, in a step 77, if the message is a normal message, the server 20 
stores the data contained in the fields EXPIRY, DISPLAYTIME and AUDIENCE, 
together with the URL of the HTML filie in a file in the store 54. Thus, for each 
normal message, the URL of the file containing the information part of the message 
5 together with the identifier or identifiers of the intended audience of the message 
as well as other data relating to the message are stored in a file in store 54. 

If the message is a short message, the text of the message together with 
the data from the fields EXPIRY and AUDIENCE are stored as a file in the store 54. 

The fields in store 54 for storing data on each message are shown in Table 
10 2 below. 

TABLE 2 



ORIGINATOR: 


identifier of originator 


WHEN: 


time of creation 


EXPIRY: 


time of expiry 


TYPE: 


short or normal message 


AUDIENCE: 


identifiers(s) of intended audience 


DISPLAYTIME: 


intended display time 


ADDRESS: 


URL of message or text of message 



The individual fields shown in Table 2 will now be described. The fields 
1 5 EXPIRY, AUDIENCE and DISPLAYTIME are the same as the corresponding fields of 
the form shown in Table 1 . The field ORIGINATOR contains the identifier of the 
originator of the message and the field WHEN contains the time of creation of the 
message. 

The field TYPE specifies whether the message is a short message or a 
20 normal message. In the case of a normal message, the field ADDRESS 
contains the URL of the file in the store 53 which contains the information part of 
the message. In the case of a short message, the field ADDRESS contains the 
actual text of the message. 

Referring now to Figure 5, there are shown the series of operations which 
25 are performed in order to enable a user to view the messages intended for the user 
on the screen of one of the clients 21 to 33. 
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In an initial step 90, the user operates the client so as to cause the client 
to log on to the server. In order to do this, the user selects the URL for the 
message service provided by the server 20. The user then is invited to enter his 
user identifier and password. In the server 20, the user identifier and password 
5 are checked against the data on the user stored in one of the files in store 55. 

Next, in a step 91, the user is invited to choose between the option for 
posting a message and the option for viewing messages. The user chooses the 
option for viewing messages. 

Next, in a step 92, the user is asked to enter his user identifier. This step 
10 is necessary in order to identify the user to the message service provided by a 
server 20. 

Next, m a step 93, the server enters the program BACKEND. The program 
BACKEND downloads programs DISPLAY and INVOKER to the client. 

Using the program DISPLAY, in a step 94, the client displays on its screen 
15 the message frameset 99. The message frameset is illustrated in Figure 6. The 
frameseT^ompns^ 

short messages and a frame 103 for displaying normal messages. After step 94, 
the clients calls the program INVOKER. The client and server then together 
perform a series of operations which are repeated automatically at intervals set by 
20 the administrator of the message service. In the present example the series of 
operations are repeated at 10 second intervals. The series of operations will be 
described with reference to steps 1 10 to 117. 

In step 110, the client requests messages intended for the user. 
In step 111, the server scans the message data in store 54 to find all 
25 messages (normal and short) intended for the user. Expired messages are ignored. 

Next, in step 112, the server creates a first list of normal messages 
intended for the user and a second list of short messages intended for the user. 
Expired messages are ignored. On the first list, the data for each normal message 
comprises the URL of the HTML message file in store 53 and the intended display 
30 time. 

For each short message, the data entered on the list comprises the text of 
the message. The two lists are then merged and formed into an HTML file which 
is transmitted to the client in a step 113. 
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Next, in a step 114, for each normal message on the list for which the 
client has not yet retrieved the message file, the client retrieves the message file 
from store 53. In a step 115, the client displays the short messages in the frame 
102 of frameset 99. In the frame 102, the short messages are passed in turn from 
5 left to right. In a step 116, the client displays the normal messages in the frame 
103. in the frame 103, each normal message is displayed for its intended 
displayed time. 

In a step 117, the client pauses until the end of the 10 second period and 
then returns to step 110. 
10 When an originator posts a message on the server 20, the originator can 

request a report which lists any members of the intended audience who have not 
retrieved the message. When an originator of a message requests such a report, 
the originator specifies the delay period between posting the message and 
establishing the report. When such a report is requested, at the end of the delay 
1 5 period, the server 20 checks whether any members of the intended audience have 
not retrieved the report. It then transmits a message containing a list of any 
members of the intended audience who have not retrieved the report. 

In the message service described above, because the messages are 
transported as files rather than e-mails, they are not subjected to the unpredictable 
20 delays experienced by e-mails. Also, because a client which is being used to 
retrieve messages is arranged to request new messages at periodic intervals, the 
messages displayed will be almost up-to-date. , 

In the arrangement shown in Figure 1, the message part of the messages 
are stored only in the message file store 53 of server 20. By way of modification, 
25 a replica of the message file store 53 could be created, for example in a server 
connected to the network 13. This would provide the advantage that each HTML 
message file would need to be transported only once from the network 20 to the 
network 13. 
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CLAIMS 

1 . A method of supplying messages in which: 

messages are stored on a server which is accessible by a group of clients 
5 operated by users, each message being stored by performing the following 
operations: 

receiving the message at said server from one of said group of clients, said 
message comprising an information part and a data part, the data part including at 
least one identifier specifying the intended audience of the message; 
10 storing the information part of the message as a file at an address in a first 

store; 

storing said address and said at least one identifier in a second store; and 

messages intended for a particular user are viewed on one of said clients 
by performing the following operations: 
15 said client transmitting requests automatically at periodic intervals to the 
server-for-mBssagesHntended-foT"S"aid _ piaTt1cular user; 

in response to each request, the server scanning the second store to 
compile a list of addresses of messages intended for said particular user; 

the server transmitting files stored at addresses specified on said list to 
20 said client; and 

said client displaying messages received by the client. 

2. A method as claimed in claim 1, in which said step of receiving a message 
at said server comprises: 

25 receiving at the server a request from one of said clients to supply the 

message to the intended audience; 

transmitting a file containing a form for completion by a user from the 
server to said client; and 

transmitting a file containing the form as completed by a user from said 
30 client to the server. 
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3. A method as claimed in claim 1 or claim 2, in which said step of 
transmitting files to said client comprises: 

transmitting said list of addresses of messages to said client; 
said client transmitting a request to the server for files stored at the 
5 addresses specified in said list; and 

transmitting files so requested from the server to said client. 

4. A method as claimed in any one of the preceding claims, in which in said 
step of receiving a message at the server, the data part of the message includes an 

10 expiry time for the message. 

5. A method as claimed in claim 4 in which, in said step of scanning the 
second store, the list excludes the addresses of messages which have expired. 

15 6. A method as claimed in any one of the preceding claims in which: 

in said step of storing the information part of the message, the message is 
stored as a HyperText Mark-up Language (HTML) file; 

in said step of storing said addresses and said at least one identifier, said 
address is the Universal Resource Locator (URL) of said HTML file. 

20 

7. A method as claimed in any one of the preceding claims, in which the 

server is an Internet server, and said group of clients is a group of Internet clients. 



BNSDOCID: <WO 9S47268A 1 _l_> 



WO 98/47268 



1/6 



PCT/GB98/01030 



21 



Fig.1 



CLIENT | 



CLIENT 




ROUTER 



ROUTER | 





BNSOOCID: <WO 9847268A1_I_> 



SUBSTITUTE SHEET (RULE 26) 



WO 98/47268 



2/6 



PCT/GB98/01030 



Fig.2. 



53 



^ 

MESSAGE 
FILES 



55 



54 



USER DATA 
FILES 



1 



MESSAGE 
DATA FILE 




WEB 
SERVER 



50 



Fig.3. 




_9847268A1 I 



SUBSTITUTE SHEET (RULE 26) 



WO 98/47268 



PCT/GB98/01030 



Fig.4A. 

( START 



USER LOGS ONTO 
SERVER 



70 



USER SELECTS OPTION 
FOR POSTING A MESSAGE 



71 



-USER— ENTERS - USER - 
IDENTIFIER 



72 



USER SELECTS TYPE OF 
MESSAGE 



73 



MESSAGE FORM DISPLAYED 
ON CLIENT 



74 



USER FILLS OUT AND 
RETURNS MESSAGE FORM 



75 



0 



BNSDOCID: <WO__9847268A 1_l_> 



SUBSTITUTE SHEET (RULE 26) 



4/6 

Fig 

Q 


.4B. 


TEXT PART OF MESSAGE 
STORED AS HTML FILE 






DATA PART < 
STORED Ai 
DATA 


OF MESSAGE 
5 MESSAGE 
FILE 



PCT/GB98/01030 



76 



77 



( END ^ 



Fig.6. 



100 



101 



102 



103 



99 



SUBSTITUTE SHEET (RULE 26) 



WO 98/47268 



5/6 



PCT/GB98/01030 



Fig.5A. 

( start"^) 







USER LOGS ONTO SERVER 






USER SELECTS OPTION 
FOR VIEWING MESSAGES 






USER ENTERS USER 
IDENTIFIER 











90 



91 



92 



SERVER DOWNLOADS 
PROGRAMS TO CLIENT 



93 



CLIENT DISPLAYS MESSAGE 
FRAMESET 



94 



CLIENT REQUESTS 
MESSAGES 



110 



© 



© 



BNSDOCID: <WO 9847268A 1_L> 



SUBSTITUTE SHEET (RULE 26) 



WO 98/47268 



PCT/GB98/01030 



© 



Fig.SB 

Q 


p 


SERVER SCANS MESSAGE 

DATA FILES TO FIND 
MESSAGES INTENDED FOR 
THE USER 






SERVER CREATES LIST FOR 
URLs FOR NORMAL 
MESSAGES AND LIST OF 
SHORT MESSAGES 






SERVER TRANSMITS BOTH 
LISTS TO CLIENT 






CLIENT RETRIEVES NEW 
NORMAL MESSAGES 






CLIENT DISPLAYS 
SHORT MESSAGES 






CLIENT DISPLAYS 
NORMAL MESSAGES 






PAUSE | 







111 



112 



113 



114 



115 



116 



SUBSTITUTE SHEET (RULE 26) 

BNSDOCID: <WO 9847268A1_I_> 



INTERNATIONAL SEARCH REPORT 



A CLASSIFICATION OF SUBJECT MATTER 

IPC 6 H04L12/58 G06F17/60 



According to International Patent Classification ((PC) or to both national classification and IPC 



national Application No 

PCT/GB 98/01030 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 6 H04L G06F 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and. where practical, search terms used) 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category ■ 



Citation of document, with indication, where appropriate, of the relevant passages 



TEUNISSEN B ET AL: "MULTIMEDIA MAIL: A 
COLOURFUL BUSINESS APPLICATION FOR 
SUCCESS" 

INFORMATION NETWORKS ANO DATA 
COMMUNICATION, PROCEEDINGS OF THE IFIP TC6 
-INTERNAT-IONAL—GONFERENGE-ON— INFORMATION- 



NETWORKS AND DATA COMMUNICATION, FUNCHAL 
MADEIRA ISLAND, PORTUGAL, APR. 18 - 21 
1994, 

no. CONF. 5, 18 April 1994, VEIGA P;DIPAK 
KHAKHAR (EDS ), 
pages 45-56, XP000593284 
see page 53, line 1 - line 14; figure 4 

US 5 177 680 A (TSUKINO HIROSHI ET AL) 5 
January 1993 

see column 4, line 28 - line 55 

-/-- 



| X I Furtner documents are listed in the continuation of box C. 



Relevant to claim No. 



1-3 



1-3 



0 



Patent family members are listed in annex. 



° Special categories of cited documents : 

"A" document defining the general state of the art which is not 
considered to be of particular relevance 

"E" earlier document but published on or after the international 
filing date 

*V document which may throw doubts on priority daim(s) or 
which ts cited to establish the publication date of another 
citation or other special reason (as specified) 

**0" document referring to an oral disclosure, use, exhibition or 
other means 

"P" document published prior to the international filing date but 
later than the priority date claimed 



T" later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

"X" document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

"Y" document of particular relevance; the claimed invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art. 

'&." document member of the same patent family 



Date of the actual completion of the international search 



13 July 1998 



Name and mailing address of the ISA 

European Patent Office, P.B. 5818 Patentlaan 2 
NL - 2280 HV Rijswijk 
Tel. (+31-70) 340-2040. Tx. 31 651 epo nl. 
Fax: (+31-70) 34O-3016 



Fonm PCT/1SA/210 (second sheet) (July 1 992) 



Date of mailing of the international search report 



06/08/1998 



Authorized officer 



Deane, E 



BNSDOCIO <WO 9847268A 1 _!_> 



page 1 of 2 



INTERNATIONAL SEARCH REPORT 



national Application No 

PCT/GB 98/01030 



C.(Continuation) DOCUMENTS CONSIDERED TO BE RELEVANT 



Category * 



Citation of document, with indication, where appropnate. of the relevant passages 



Relevant to claim No. 



WO 96 34341 A (B0B0 CHARLES II) 31 October 
1996 

see page 14, line 23 - page 17, line 7; 
figures 2.3 

TOLLY K ET AL: "GROW UP TODAY'S 
LAN-BASED E-MAIL APPLICATIONS ARE MORE 
THAN TOYS, BUT LESS THAN TOOLS" 
DATA COMMUNICATIONS, 
vol. 23, no. 16, 1 November 1994, 

74 - 76, 78, 80, 82, 84, 



pages 70-72, 
XP000471524 
see page 78. 
see page 72. 



box ; 

right-hand column, line 18 



page 76. left-hand column, line 6 

THIMM H ET AL: "A MAIL-BASED TELESERVICE 
ARCHITECTURE FOR ARCHIVING AND RETRIEVING 
DYNAMICALLY C0MP0SABLE MULTIMEDIA 
DOCUMENTS" 

MULTIMEDIA TRANSPORT AND TELESERVICES . 
INTERNATIONAL COST 237 WORKS PROCEEDINGS, 
VIENNA, NOV. 13 - 15. 1994, 

13 November 1994. HUTCHISON D;DANTHINE A; 
LEOPOLD H; COULSON G (EDS ), 
pages 14-34, XP000585292 
see page 16, line 20 - page 18, line 5; 
figures 1,2 

"WPI WORLD PATENT INFORMATION DERWENT" 
WPI WORLD PATENT INFORMATION DERWENT, 
vol. 46, no. 91, XP002071104 
Week 9146, AN 91-337344 
& ANON. : "Expiry date marking method for 
electronic mail" 
RESEARCH DISCLOSURE, 
vol. 330, no. 36, 10 October 1991, 

EP 0 375 143 A (IBM) 27 June 1990 
see column 2, line 6 - line 26 

EP 0 662 763 A (AT & T CORP) 12 July 1995 
see column 6, line 23 - line 38; figure 3 
see column 7, line 20 - line 42 



Form PCT/1SAI210 (continuation ol second sheet) (July 1 992) 



6,7 



4,5 



page 2 of 2 



BNSOOCID: <WO_9847268A1J_ 



Information on patent family members 


national Application No 

PCT/G8 98/01030 


Patent document 
cited in search report 


Publication 
date 


Patent family 
member(s) 


Publication 
date 



US 5177680 



WO 9634341 



05-01-1993 
31-10-1996 



JP 



1108830 A 



US 



5675507 A 



26-04-1989 
07-10-1997 



EP 


0375143 


A 


27-06- 


1990 


US 


5093918 


A 


03-03-1992 












CA 


1319759 


A 


29-06-1993 












DE 


68924525 


D 


16-11-1995 












DE 


68924525 


T 


30-05-1996 












JP 


1950185 


C 


10-07-1995 












JP 


2194750 


A 


01-08-1990 












JP 


6083250 


B 


19-10-1994 


EP 


0662763 


A 


12-07- 


1995 


AU 


8180194 


A 


20-07-1995 












JP 


7221852 


A 


18-08-1995 



Form PCT71SA/210 (patent fainSy annex) (July 1992) 
BNSDOCID: <WO 8847268A 1 J_> 



